home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01a.txt / 000059_icon-group-sender _Tue Jun 13 07:47:06 2000.msg < prev    next >
Internet Message Format  |  2002-01-03  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA02504
  4.     for icon-group-addresses; Tue, 13 Jun 2000 07:46:28 -0700 (MST)
  5. Message-Id: <200006131446.HAA02504@baskerville.CS.Arizona.EDU>
  6. To: "Frank J. Lhota" <NOSPAM.Frank.Lhota@lexma.meitech.com>
  7. Cc: icon-group@optima.CS.Arizona.EDU
  8. Subject: Re: User defined operators for Icon 
  9. Date: Mon, 12 Jun 2000 17:30:38 -0700
  10. From: Clinton L Jeffery <jeffery@bo.Egr.UNLV.EDU>
  11. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  12. Status: RO
  13. Content-Length: 1525
  14.  
  15.  
  16. The discussion of extending Icon with new types is very interesting.
  17. I have a couple additions to the ideas people have contributed so far:
  18.  
  19. 1. You can define the behavior of functions such as image() and write() for
  20. new types, by providing procedures with those names.  It is awkward to make
  21. this work when independently written types (say, in procedure libraries)
  22. need to be used together; they can't both supply a definition of image(),
  23. though you can devise passable workarounds for this.
  24.  
  25. 2. You can always get at the original definitions of overloaded functions,
  26. using the proc() function.
  27.  
  28. 3. You can devise explicit type conversion functions between record types
  29. and existing types, you just can't do implicit ones.
  30.  
  31. Object oriented programming is all about creating a strong facility for
  32. writing user-defined types.  I can't say whether operator overloading or
  33. implicit type conversions are appropriate or desirable for Icon, but
  34. Unicon's object-oriented facilities (the successor and replacement for Idol)
  35. would benefit directly from Frank's suggestions.
  36.  
  37. There are some controversial issues (read this as: "problems") involving
  38. operator overloading and type conversions as found in C++.  I will probably
  39. think about them carefully, and discuss them on the Unicon mailing list,
  40. before I go and implement them for Unicon.  Besides, I have to finish
  41. implementing packages and get the UNLV release of Unicon for UNIX and
  42. Windows out the door, before I think about any other features. :-)
  43.  
  44. Clint, jeffery@cs.unlv.edu
  45.